In certain operating systems, the applications (i.e., processes) run in their own address space and any attempt made by an application to access address space that does not belong to the application (i.e., a memory-address violation) results in abnormal termination of the application. Abnormal termination of an application may also result from an illegal instruction, a bus error, or a user-generated quit signal. Upon the abnormal termination of an application, a device within the kernel of the operating system causes process state information to be written or “dumped” to a local permanent storage device. The file that is written to the local permanent storage device is typically named “core” and is generally referred to as the “core file.” The process of saving the core file to a local permanent storage device is often referred to as a “core dump” or a “crash dump.”
The core file may include information that may be used to diagnose the cause of the application crash. In the context of a Java® runtime environment, the core file may include the processor registers (e.g., program counter, stack pointer), processor and operating system flags, a list of loaded modules (along with information regarding where they are loaded) from the application as well as memory management information, which may include the Java® heap and the native heap. A Java® heap refers to the area of memory which contains all of the objects created by an application running on a Java® virtual machine. A “native heap,” as used herein, refers to the area of memory which contains the code compiled by a compiler (e.g., Just-in-Time (JIT) compiler). The source code of a Java® program is compiled into an intermediate language called “bytecode,” which cannot run by itself. The bytecode is converted (interpreted) into machine code at runtime by a compiler, such as a JIT compiler. This native machine code may then be stored in the native heap.
The core file may be used to diagnose the cause of the application crash, especially in situations where the problem can be re-created only in the customer environment, where the crashes are due to object or memory corruption or when the interactive debugger cannot be used in the failing environment.
Due to the complexity in diagnosing the cause of an application crash, multiple core files may have to be collected. For example, a core file may have to be collected at every instance an application crashes in diagnosing corruption issues. In another example, a core file may have to be collected at various intervals of time when a memory leak occurs. A memory leak occurs when a program consumes memory but is unable to release it back to the operating system. If too many memory leaks occur, these memory leaks can usurp all of memory and bring everything to a halt or slow the processing considerably.
The difficulty in using these core files to analyze and diagnose application crashes is their considerable size. Core files may span anywhere from a few 100 megabytes to a few gigabytes. As a result, core files may be difficult to store or transfer to a diagnostics environment.
If unnecessary information (unnecessary in analyzing and diagnosing the application crash) in the core file could be filtered from the core file, then the core file could be more appropriately sized thereby enabling core files to be more easily stored or transferred to a diagnostic environment.